Microservices Security in Action by Prabath Siriwardena & Nuwan Dias

Author:Prabath Siriwardena & Nuwan Dias [Siriwardena, Prabath & Dias, Nuwan]
Language: eng
Format: epub
Publisher: Manning Publications Co.
Published: 0101-01-01T00:00:00+00:00

11.7.1 Talking to the Kubernetes API server from the STS

Let’s say, for example, we need the STS to talk to the API server. Ideally, we’ll do that in the STS code itself. Because this is just an example, we’ll use curl from a container that runs the STS. Use the following kubectl command to directly access the shell of an STS Pod. Because we have only one container in each Pod, we can simply use the Pod name (sts-deployment-69b99fc78c-j76tl) here:

\> kubectl -it exec sts-deployment-69b99fc78c-j76tl sh #

After you run the command, you end up with a shell prompt within the corresponding container. Also, we assume that you’ve followed along in section 11.6.1 and updated the STS Deployment, where now it runs under the ecomm service account.

Because we want to use curl to talk to the API server, we need to first install it with the following command in the STS container. And because the containers are immutable, if you restart the Pod during this exercise, you’ll need to install curl again:

# apk add --update curl && rm -rf /var/cache/apk/*

To invoke an API, we also need to pass the default token secret (which is a JWT) in the HTTP authorization header. Let’s use the following command to export the token secret to the TOKEN environment variable. As we’ve previously mentioned, the default token secret is accessible to every container from the /var/run/secrets/kubernetes.io /serviceaccount/token file:

# export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

The following curl command talks to the Kubernetes API server to list all the metadata associated with the current Pod. Here, we pass the default token secret, which we exported to the TOKEN environment variable, in the HTTP authorization header. Also, inside a Pod, Kubernetes itself populates the value of the HOSTNAME environment variable with the corresponding Pod name, and the kubernetes.default .svc hostname is mapped to the IP address of the API server running in the Kubernetes control plane:

# curl -k -v -H "Authorization: Bearer $TOKEN" \ https://kubernetes.default.svc/api/v1/namespaces/default/pods/$HOSTNAME

In response to this command, the API server returns the HTTP 403 code, which means the ecomm service account isn’t authorized to access this particular API. In fact, it’s not only this specific API; the ecomm service account isn’t authorized to access any of the APIs on the API server! That’s the default behavior of GKE. Neither the default service account that Kubernetes creates for each namespace nor a custom service account you create are associated with any roles.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.